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1  Introduction 

A  distributed  system  is  composed  of  different  parts  that  work  together  to  provide 
one  or  more  functions.  Its  state  space  grows  exponentially  with  the  number  of 
components.  So  it  becomes  extremely  difficult  to  consider  all  the  possible  behav¬ 
iors  of  the  system,  and  consequently,  difficult  or  impossible  to  make  guarantees 
about  it.  Here  we  report  on  techniques  to  reduce  the  state  space  and  to  verify 
strong,  nontrivial  properties.  This  contributes  to  a  framework  to  support  the 
development  of  a  distributed  system:  a  specification  serves  to  document  the  sys¬ 
tem;  it  can  be  executed  to  provide  some  debugging,  and  to  simulate  the  system; 
and  it  can  be  subjected  either  directly  or  after  some  modular  transformations 
to  various  kinds  of  formal  analyses. 

This  research  developed  techniques  that  modularly  transform  the  specifica¬ 
tion  of  a  system  to  be  analyzed.  Two  simple  transformations  implement  on-the- 
fly  state-space  reductions,  one  a  symmetry  reduction,  the  other  a  partial-order 
reduction.  A  third  transformational  technique  allows  the  verification  of  proper¬ 
ties  that  are  not  readily  expressible  in  linear  temporal  logic. 

In  designing  a  good  system  there  must  be  a  clear  understanding  of  the  prop¬ 
erties  it  should  satisfy.  Some  mathematical  fields  deal  with  structure  and  rea¬ 
soning  about  properties,  and  these  are  the  fields  that  underlie  formal  methods 
-  rigorous  techniques  for  the  specification  and  analysis  of  computational  sys¬ 
tems.  So  formal  methods  are  well  poised  to  describe  the  structure  of  distributed 
systems,  and  reason  about  their  properties. 

There  are  a  variety  of  formal  methods  for  the  specification  and  analysis 
of  systems.  They  differ  in  the  mathematics  that  underlie  them,  the  kinds  of 
properties  they  can  specify  and  analyze,  and  the  available  tools  associated  with 
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them.  In  general,  there  are  two  basic  approaches  to  the  analysis  and  verifica¬ 
tion  of  properties:  theorem  proving  and  state-space  exploration.  Of  the  two 
approaches,  theorem  proving  is,  in  theory,  applicable  to  systems  with  state 
spaces  of  any  size,  but  requires  a  high  level  of  expertise;  while  a  state-space 
exploration  approach  is  applicable  only  to  finite-state  systems,  but  requires  less 
expertise,  and  is  more  automatic.  Both  formal  approaches  require  more  power¬ 
ful  techniques  to  provide  practical  support  for  the  development  of  distributed 
systems. 

The  formal  system  selected  for  this  research  is  Maude  —  an  executable  logic 
of  concurrent  change.  It  has  been  shown  to  be  a  framework  for  a  wide  range 
of  computational  models  and  logics.  This  means  not  only  that  models  and 
properties  expressible  in  these  formal  systems  can  be  expressed  and  analyzed 
in  Maude,  but  that  the  sound  integration  of  various  such  descriptions  becomes 
possible,  and  with  this  more  powerful  means  of  studying  systems.  Furthermore, 
Maude  provides  various  formal  methods  to  study  a  specification  as  it  is  being 
developed.  Executable  specifications  can  serve  to  debug  the  specification,  and 
provide  prototypes  of  the  specified  system.  A  search  command  serves  to  explore 
the  state  space,  making  it  possible  to  check  the  existence  of  different  scenarios 
in  the  system,  as  well  as  checking  invariant  properties  of  the  system.  Model 
checking  makes  possible  the  verification  of  properties  expressible  in  linear  tem¬ 
poral  logic.  In  isolation  and  in  combination  these  methods  can  be  used  to  study 
a  specification  as  it  is  being  developed.  The  main  objective  of  this  research 
was  to  develop  techniques  that  would  allow  the  application  of  these  methods  to 
specifications  of  systems  of  larger  size  and  more  complex  properties. 

To  motivate  and  evaluate  the  techniques  developed,  a  client-server  protocol 
was  studied,  a  simplification  of  the  Chain-Replication  protocol  developed  by 
van  Renesse  and  Schneider  [7].  Three  techniques  were  developed:  an  on-the- 
fly  symmetry  reduction  technique  that  modularly  augments  a  specification,  a 
technique  with  auxiliary  data  to  support  the  verification  of  strong  properties, 
and  a  technique  to  reduce  the  state  space  using  a  partial-order  approach. 

All  these  techniques,  though  only  applied  to  a  singe  protocol  in  this  study, 
are  general  techniques  that  could  be  applied  to  a  wide  range  of  protocols.  The 
symmetry-reduction  technique  can  be  applied  to  any  system  with  identical  com¬ 
ponents.  This  technique  was  very  effective  in  reducing  the  state  space.  While 
some  techniques  are  very  effective  in  reducing  the  state  space  when  verifying 
shallow  properties,  verification  of  strong  properties  is  a  greater  challenge.  The 
second  technique  permitted  the  verification  of  the  strong  property  the  Chain- 
Replication  protocol  should  satisfy,  and  should  be  applicable  to  the  verification 
of  strong  properties  of  other  protocols.  Finally,  the  partial-order  reduction  tech¬ 
nique  developed  resulted  in  a  small  reduction  of  the  state  space  when  applied  to 
the  client  server  protocol  under  study.  The  effectiveness  of  this  technique,  how¬ 
ever,  is  determined  by  the  interdependencies  of  the  transitions  of  the  protocol. 
So  further  evaluation  of  this  technique  should  include  its  application  to  other 
protocols.  A  significant  innovation  of  this  technique  is  that  it  is  applied  to  the 
specification  of  a  system,  rather  than  to  the  model  checking  algorithm  that  will 
be  used  to  verify  properties  of  the  specification,  which  is  the  usual  case.  This 
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makes  possible  the  exploitation  of  properties  of  the  specification,  that  might 
not  be  possible  when  the  technique  is  applied  to  the  model  checker.  Thus  there 
should  be  further  investigation,  optimization  and  evaluation  of  this  technique. 
I  will  be  presenting  a  paper  describing  this  research  at  the  7th  International 
Workshop  on  Rewriting  Logic  and  its  Applications,  WRLA08. 

Section  2  introduces  Maude  preliminaries,  in  particular  those  related  to 
object-based  specifications.  The  specification  of  the  simplication  of  the  Chain- 
Replication  protocol  is  presented  in  Section  3.  The  next  section  discusses  the 
on-the-fly  symmetry  reduction  technique  and  its  application  to  the  protocol. 
Section  5  motivates  and  describes  a  technique  that  uses  auxiliary  data  to  verify 
the  strong-consistency  property  this  protocol  should  satisfy.  Section  6  describes 
a  partial-order  reduction  technique  that  modifies  the  specification  of  the  proto¬ 
col.  The  conclusions  and  future  work  are  presented  in  Section  7. 


2  Maude  Preliminaries 

Maude  [2]  [3]  is  an  executable  language  based  on  rewriting  logic  [5],  a  logic 
of  concurrent  change.  In  rewriting  logic,  a  concurrent  system  is  specified  by 
a  rewrite  theory  TZ  =  ( Y,,E,R ),  where  ( Y,,E )  is  an  equational  theory  with 
the  signature  E  specifying  sorts  (types)  and  operations;  E,  a  set  of  equations 
on  E- terms:  and  R,  a  set  of  labelled  conditional  rewrite  rules,  of  the  form 
l  :  t  — >  t!  if  cond.  The  equational  theory  describes  the  distributed  structure 
of  the  system,  while  the  conditional  rewrite  rules  define  its  basic  concurrent 
transitions. 

A  rewrite  theory  corresponds  to  a  system  module  in  Maude.  For  system 
modules  that  satisfy  some  executability  requirements  [3] ,  a  rewrite  rule  describes 
not  only  a  transition  between  states,  but  a  transition  between  equivalence  classes 
of  states,  where  the  equivalence  classes  are  defined  by  the  equations  of  the 
rewrite  theory.  Thus,  properly  defined  executable  specifications  in  Maude  have 
this  condensed  and  reduced  state  space. 

Maude  supports  object-based  models,  with  a  predefined  module  declaring 
sorts  for  the  essential  concepts,  namely  Object,  Msg,  and  Configuration. 

mod  CONFIGURATION  is  sorts  Object  Msg  Configuration  .  ... 


A  configuration  is  a  multiset  of  messages  and  objects.  In  particular,  a  single 
message  or  a  single  object  is  a  configuration.  Maude  supports  subsorts,  so  this 
can  be  expressed  as  follows: 


subsort  Object  Msg  <  Configuration  . 

A  configuration  is  described  by  a  term  of  sort  Configuration  constructed  with 
the  following  operators: 

op  none  :  ->  Configuration  [ctor]  . 

op  _  :  Configuration  Configuraton  ->  Configuration 

[ctor  config  assoc  comm  id:  none]  . 
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The  first  takes  no  arguments,  and  represents  a  configuration  with  neither  objects 
nor  messages.  The  second  takes  two  arguments,  which  are  juxtaposed  (the  _  is 
a  placeholder,  and  there  is  no  syntax  between  the  arguments),  and  is  declared 
with  attributes  of  a  multiset:  it  is  associative,  commutative,  and  has  identity 

none. 

A  typical  configuration  has  the  form  0\  . . .  On  M\ . . .  Mm,  where  the  O’ s 
represent  objects  and  the  M’s  messages.  The  most  general  form  of  a  conditional 
rewrite  rule  for  an  object-based  model  is  of  the  form: 

l:M1...Mm  01...0n-+0[1...0'ik  Qi  ...  Qp  Mi . . .  Mq  if  C 

This  rule,  labelled  by  l ,  represents  transitions  in  which,  if  the  condition  C  holds 
for  the  configuration  on  the  left  side  of  the  rule,  messages  Mi . . .  Mm  are  con¬ 
sumed;  the  states  of  some  of  the  objects  0\  ...  On  change,  becoming  0\  . . .  O', , 
k  <  n,  with  the  rest  disappearing;  and  new  objects  Qi . . .  Qp  and  messages 
Mi . . .  Mq  are  created. 


3  A  Client-Server  Protocol 

The  client-server  protocol  studied  is  a  simplified  version  of  the  Chain- Replication 
protocol  developed  by  van  Renesse  and  Schneider  [7].  Their  protocol  has  m 
servers  and  n  clients,  but  from  the  perspective  of  a  client  there  is  a  single 
server.  The  innovation  of  the  protocol  is  in  achieving  fault  tolerance  and  high 
throughput  through  the  collective  service  provided  by  the  servers,  but  the  state- 
explosion  problem  is  present  in  configurations  with  a  single  server  and  several 
clients.  The  simplified  version  of  the  Chain  Replication  protocol  is  used  to 
develop  techniques  to  reduce  the  state  space,  and  to  define  (and  check  in  its 
limiting  case)  the  property  the  Chain- Replication  protocol  should  satisfy. 

In  this  protocol  the  server  stores  an  object,  whose  value  a  client  may  observe 
by  making  queries,  or  change  by  requesting  updates.  Informally,  the  property 
this  protocol  must  satisfy  is  that  any  response  to  a  query  by  a  client  must  reflect 
prior  updates. 

An  object-based  model  of  this  protocol  has  servers  and  clients  as  objects, 
and  requests  and  replies  as  messages. 

sorts  Client  Server  .  subsorts  Client  Server  <  Object  . 

sorts  Request  Reply  .  subsorts  Request  Reply  <  Msg  . 

A  client  is  represented  using  the  following  operator: 

op  <  client_  I  request-count  outstanding  value  :_> 

:  NzNat  Nat  Bool  Value  ->  Client  [ctor]  . 

A  nonzero  natural  serves  to  identify  a  client,  and  a  request  count  is  used  to 
limit  the  number  of  requests  a  client  can  make,  ensuring  that  the  state  space 
remains  finite.  Each  client  keeps  the  value  of  the  object,  as  it  has  observed  it 
through  requests  to  the  server.  The  protocol  stipulates  that  a  client  may  have 
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at  most  one  outstanding  request.  For  the  purposes  of  this  study  it  is  not  useful 
to  consider  failures  or  messages  lost,  and  so  as  long  as  there  is  an  outstanding 
request  the  client  may  not  issue  another.  Boolean  attribute  outstanding  indicates 
whether  the  client  has  initiated  a  request  for  which  it  is  expecting  a  reply. 

A  request  instructs  the  server  to  perform  an  operation  on  the  object:  a  query 
is  a  read  operation,  while  an  update  is  a  write  operation. 

op  query [_]  :  NzNat  ->  Request  [ctor]  . 
op  update :  NzNat  Value  ->  Request  [ctor]  . 

The  action  of  a  client  sending  a  query  is  represented  by  the  following  conditional 
rule. 

crl  [send-query] 

<  client  N  I  request-count  :  K,  outstanding  :  false,  value  :  V  > 

=>  <  client  N  I  request-count  :  s  K,  outstanding  :  true,  value  :  V  > 

query  [M]  if  K  <  lim  . 

Similarly,  a  client  sending  an  update  is  represented  by  the  following  rule: 

crl  [send-update] 

<  client  N  I  request-count  :  K,  outstanding  :  false,  value  :  V  > 

=>  <  client  N  I  request-count  :  s  K,  outstanding  :  true,  value  :  V  > 

update[N  :  val(N,  s  K)]  if  K  <  lim  . 

Either  request  may  be  made  only  if  there  is  no  outstanding  request,  that  is,  if 
outstanding  is  false.  If  the  request  is  a  query,  it  is  represented  symbolically  by 
query [n],  which  identifies  the  requesting  client.  If  the  request  is  an  update,  it 
must  include  the  value  the  client  is  submitting.  This  is  represented  symbolically 
as  vai(N,  k),  which  indicates  that  this  is  the  value  client  N  submitted  in  its  s  K-th 
request. 

How  requests  or  replies  are  transported  from  sender  to  receiver  is  not  deter¬ 
mined  by  the  protocol,  and  so  a  term  of  sort  Msg  in  the  configuration  represents 
a  message  that  has  been  sent  but  not  received. 

The  server  receives  and  processes  requests.  It  is  represented  using  the  fol¬ 
lowing  operator: 

op  <  server  I  pending  value  :_> 

:  RequestQueue  Value  ->  Server  [ctor]  . 

It  receives  a  request  by  removing  it  from  the  configuration  and  enqueueing  it  in 
the  pending  queue. 

rl  [get-request] 

<  server  I  pending  :  Q,  value  :  V  >  R 
=>  <  server  I  pending  :  Q  ;  R,  value  :  V  >  . 

As  the  server  processes  a  request  of  a  client,  it  sends  a  reply  confirming  the 
operation.  It  replies  to  a  query  with  the  current  value  of  the  object;  and  to  an 
update  with  the  value  the  client  had  requested  be  assigned  to  the  object,  which 
is  now  the  current  value.  So  a  reply  has  the  following  syntax. 
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op  reply-to :  NzNat  Value  ->  Reply  [ctor]  . 

where  the  first  argument  identifies  the  client  to  which  it  is  addressed. 

The  act  of  the  server  processing  a  request  and  replying  is  represented  by  a 
single  rule.  Processing  a  query  preserves  the  value  of  the  object. 

rl  [respond-to-query] 

<  server  I  value  :  V,  pending  :  query [N]  ;  Q  > 

=>  <  server  I  value  :  V,  pending  :  Q  >  reply-to [N  :  V]  . 

Processing  an  update  may  change  it. 

rl  [respond-to-update] 

<  server  I  value  :  V’,  pending  :  update [N  :  V]  ;  Q  > 

=>  <  server  I  value  :  V,  pending  :  Q  >  reply-to [N  :  V]  . 

A  reply  in  the  configuration  represents  a  message  in  transit  from  the  server 
to  some  client.  A  client  receives  a  reply  by  the  following  rule. 

rl  [get-reply]  : 

reply-to [  N  :  V’  ] 

<  client  N  I  request-count  :  K,  outstanding  :  true,  value  :  V  > 

=>  <  client  N  I  request-count  :  K,  outstanding  :  false,  value  :  V’  >  . 

The  attribute  outstanding  becomes  false,  since  receiving  the  reply  concludes  the 
operation. 

Thus,  the  state  of  this  system  consists  of  one  server,  one  or  more  clients, 
and  possibly  various  requests  and  replies.  This  configuration  is  enclosed  within 
delimeters  as  follows: 

sort  TConf iguration  . 

op  {_}  :  Configuration  ->  TConf iguration  [ctor]  . 

representing  the  state  as  a  term  of  sort  TConfiguration. 

To  analyze  a  protocol  using  methods  that  explore  the  state  space  requires 
that  the  protocol  be  instantiated.  Two  parameters  characterize  an  instantiation 
of  the  client-server  protocol  just  described:  size,  the  number  of  clients;  and 
lim,  the  number  of  requests  a  client  may  make.  The  server  and  all  clients  are 
initialized  with  a  special  value,  and  in  all  experiments  lim  was  3. 

The  search  command,  which  is  part  of  the  Maude  system,  allows  one  to 
explore  the  state  space  in  a  variety  of  ways  (see  [3]).  Through  arguments  and 
various  forms  it  may  return  all  states  (for  finite  state  spaces),  or  all  states 
satisfying  some  property,  or  the  first  n  states  it  finds,  for  a  specified  n.  The 
result  of  the  command  includes  the  number  of  states  examined  in  obtaining  the 
result.  Table  1  shows  the  results  of  various  experiments  in  which  the  final  states 
of  a  given  instantiation  were  requested,  using  the  following  command: 

search  {  init(size)  }  =>!  TC : TConf iguration  . 

For  the  instantiation  of  size  4,  that  is,  with  one  server  and  four  clients,  after 
much  swapping  the  computation  would  abort.  These  results  show  that  even  for 
small  instantiations  of  a  very  simple  protocol  state  spaces  can  be  very  large. 
The  next  section  describes  a  way  of  reducing  the  state  space. 
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size 

2 

3 

4 

total  states 
final  states 

4,933 

37 

952,747 

511 

>  4, 194,  304 

cpu  time  (ms) 

290 

35,978 

628,583 

real  time  (ms) 

2,454 

45,009 

22,307,029 

Table  1:  Metrics  for  basic  specification. 


4  Symmetry  Reduction 

Many  distributed  systems  include  identical  components.  Thus,  if  one  such  com¬ 
ponent  reaches  a  particular  state  in  one  of  the  possible  behaviors  of  the  sys¬ 
tem,  an  identical  component  would  reach  the  same  state  in  a  similar  behavior. 
Exploiting  symmetry  as  a  general  approach  is  not  new.  When  and  how  it  is 
exploited  can  result  in  different  techniques  and  effectiveness.  This  section  first 
presents  mathematical  preliminaries  for  exploiting  symmetry.  (For  a  more  com¬ 
plete  presentation  see  [1]  [4] .)  Then  it  describes  a  class  of  systems  and  how  to 
use  symmetry  to  reduce  the  state  spaces  of  these  systems. 

4.1  Mathematical  Preliminaries 

A  transition  system  is  a  pair  A  =  ( A ,  —>.4)  where  A  is  a  set  of  states  and 
— >_4<£  A  x  A  is  a  binary  relation  called  the  transition  relation.  A  permutation 
7r  on  a  finite  set  A  is  a  function  n  :  A  — >  A  that  is  one-to-one  and  onto.  It  is 
an  automorphism  on  A  if  it  is  such  that  for  all  a,  a1  €  A,  a  —>,4  a '  if  and  only 
if  7T a  *Ka'  ■  Given  an  automorphism  n  on  A,  ao, . . .  an  is  a  path  in  A  if  and 

only  if  7rao, . . .  tt an  is  a  path  in  A.  Any  set  of  automorphisms  on  A  closed  under 
composition  and  the  inverse  operation  is  a  group.  An  automorphism  group  G  on 
A  induces  a  relation  ~g:  A  x  A  such  that  a  ~g  cl'  if  and  only  if  there  exists  an 
automorphism  tt  £  G  such  that  a  =  ira! .  A  congruence  on  A  is  an  equivalence 
relation  ss  where  for  all  ai,  02  €  A  such  that  <i\  «  a2,  if  there  exists  a £  A  such 
that  01  — >.4  a[,  then  there  is  a'2  £  A  such  that  a!x  «  a2  and  a2  —M  a2.  The 
relation  is  a  congruence  on  A. 

Let  [a]  denote  the  class  of  states  equivalent  to  a.  For  any  a,  a'  £  A,  if 
a  —>,4  a',  then  for  all  a\  €  [a]  there  exists  a[  £  [a']  such  that  ai  —>.4  a!x. 
A  quotient  transition  system  Ac  =  (■ Aq ,  — )  of  transition  system  A  with 
respect  to  a  permutation  group  G  is  defined  by  Aq  =  {[a]  \  a  £  A}  and 
—>Ag=  {H  — *Ag  M  I  a  a'}-  Given  an  equivalence  class  [a]  in  Ag, 
some  *a  £  [a]  may  be  chosen  to  represent  [a],  and  a  quotient  representative 
system  Ag*  =  (Ag*,— Mg*)  °f  maY  be  defined  by  Ag*  =  {*a  \  [a]  £  Aq}  and 
— >ag.=  {*a  ~^ag*  *a'  I  [°]  ~ i >Ag  [a1l-  Thena  is  reachable  from  a 0  in  A  if  and 
only  if  *a  is  reachable  from  *ao  in  Ag*- 
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4.2  States,  Indexed  Objects  and  Automorphisms 

In  the  client-server  protocol,  clients  are  specified  uniformly  as  indexed  objects, 
and  indices  are  further  used  to  represent  values  symbolically.  Thus,  the  states 
of  the  system  may  be  expressed  as  functions  on  indices.  More  generally,  a  state 
with  a  finite  set  of  identical  components  may  be  described  using  a  finite  set  of 
indices  /,  and  a  function  s  :  I  —>  A,  where  A  is  a  set  of  states.  A  permutation 
7Tj  :  /  — >  I  induces  a  permutation  n  :  A  — ■>  A  defined  by  i t  s(i\, . . .  ,in)  = 
s{tt , . . . ,  7r iin).  The  question  now  is  which  permutations  on  states  induced  by 
permutations  on  indices  are  automorphisms. 

To  determine  this,  consider  the  effect  of  permuting  indices  on  each  of  the 
rules  of  the  specification.  A  close  examination  of  all  the  rules  of  the  client-server 
protocol  shows  that  whether  a  rule  is  enabled  is  independent  of  the  values  of 
indices.  Thus,  for  the  client-server  protocol  all  permutations  on  indices  induce 
permutations  on  states  that  are  automorphisms.  This  will  hold  for  any  speci¬ 
fication  in  which  objects  with  identical  behavior  are  specified  uniformly  using 
indices.  Two  objects  have  identical  behavior  when  their  set  of  possible  states  is 
the  same,  and  whenever  they  have  the  same  state,  they  react  in  the  same  way. 
Next,  the  fact  that  all  permutations  of  indices  induce  automorphisms  on  states 
is  exploited  in  a  technique  for  reducing  the  state  space  on  the  fly. 

4.3  On-the-fly  State-Space  Reduction 

To  analyze  a  system  using  state-space  exploration  methods  the  parameters  of  the 
specification  must  be  instantiated.  In  particular,  a  system  with  identical  com¬ 
ponents  must  be  instantiated  with  a  fixed  number  of  such  components,  using 
indices  to  differentiate  among  them.  As  seen  above,  the  set  of  all  permutations 
of  these  indices  induces  a  group  Q  of  permutations  on  states  that  are  automor¬ 
phisms.  The  equivalence  class  with  respect  to  Q  for  state  s  is  [s]  =  {7rs  |  n  G  Q}, 
and  some  *s  €  [s]  is  selected  as  its  representative.  We  consider  how  to  compute 
with  representatives  of  these  equivalence  classes. 

There  is  no  guarantee  that  transitions  map  representative  states  to  represen¬ 
tative  states.  So  there  is  the  need  to  recognize  when  a  transition  has  occurred, 
and  to  obtain  the  representative  corresponding  to  the  state  resulting  from  the 
transition. 

From  a  specification  TZ,  we  construct  in  a  modular  way  one  that  implements 
on-the-fly  state-space  reduction,  TZ*  =  (EUE*,£U£*, R').  Signature  £*  and 
equations  E*  define  permutations,  how  to  apply  them,  construct  equivalence 
classes,  and  chose  representative  states,  and  the  set  of  rules  R'  is  a  trivial  trans¬ 
formation  of  R. 

New  syntax  and  equations  in  ( "E*,E *)  define  permutations  on  indices. 

sorts  Replacement  Perm  .  subsort  Replacement  <  Perm  . 

op  _ | ->_  :  NzNat  NzNat  ->  Replacement  [ctor]  . 

op  _  :  Perm  Perm  ->  Perm  [ctor  assoc]  . 

The  application  of  a  permutation  p  to  a  term  t  is  expressed  as  p  »  t.  We  do  not 
present  the  definition  of  permutations  on  indices,  but  indicate  that  all-perms  n 


is  the  group  of  all  permutations  on  (1, . . . ,  n}. 

For  the  client-server  protocol  the  permutation  on  states  is  specified  by  equa¬ 
tions  effecting  the  change  of  indices  throughout  a  term  representing  a  state.  For 
example,  the  effect  of  such  a  permutation  on  a  symbolic  value  and  on  a  reply  is 
given  by: 

eq  P  »  val (I ,  K)  =  val(P  »  I ,  K)  . 

eq  P  >>  reply-to[I  :  V]  =  reply-to[P  >>  I  :  P  >>  V]  . 

while  the  effect  on  clients  and  servers  is  as  follows: 

eq  P  >>  <  client  I  I  request-count  :  K,  outstanding  :  B,  value  :  V  > 

=  <  client  (P  >>  I)  |  request-count  :  K,  outstanding  :  B,  value  :  P  »  V  >  . 

eq  P  >>  <  server  |  pending  :  Q,  value  :  V  > 

=  <  server  I  pending  :  P  >>  Q,  value  :  P  >>  V  >  . 

The  augmentation  (E *,E*)  to  the  original  specification  TZ  =  (E ,E,R)  also 
defines  how  to  select  a  representative  among  the  states  in  [s].  This  is  defined 
using  a  predefined  parametric  predicate  on  terms  that  Maude  provides.  Maude 
is  a  reflective  language.  Every  term,  equation  and  rule  can  be  represented  at  a 
metalevel.  At  this  level  Maude  defines  a  total  order  on  the  metarepresentations 
of  terms.  This  total  order  can  be  checked  from  the  ground  or  object  level  with 
the  predicate  it.  Thus,  if  t\  and  t2  are  terms  at  the  object  level,  they  have 
some  metarepresentations  Tj  and  T2  at  the  metalevel.  Because  there  is  a  total 
order  on  metarepresentations  of  terms,  for  distinct  Tj  and  T2,  the  predicate 
it(fi,t2)  is  defined  to  be  true  if  and  only  if  T\  precedes  T2.  This  predicate  is 
used  to  select  a  representative  for  an  equivalence  class  [s],  where  s  is  a  term 
representing  a  state  of  the  system.  The  representative  is  chosen  to  be  the 
state  whose  metarepresentation  is  least  among  the  metarepresentations  of  all 
the  states  in  [s]. 

Let  s  be  any  state  of  the  system  specified  by  TZ  =  (E ,E,R).  If  the  system 
is  object-based,  state  s  is  a  term  of  sort  Configuration.  Introduce  the  following 
operators: 

op  all-perms  :  ->  PermSet  . 

op  _|_  :  PermSet  Configuration  ->  Configuration  [frozen  (1  2)]  . 

The  constant  ail-perms  is  the  group  of  all  permutations  on  the  set  of  indices 
{1, . . .  ,n},  where  n  is  the  number  of  identical  components  in  the  instantiated 
system.  The  operator  _  I  _  applies  a  set  of  permutations  to  a  state,  and  returns 
the  representative  of  the  resulting  set  of  states.  This  operator  takes  two  argu¬ 
ments,  and  its  attribute  frozen  (l,  2)  prohibits  the  application  of  rules  to  either 
argument.  The  selection  of  the  representative  of  [s],  for  a  configuration  state  s 
is  defined  for  Configuration  C,  Perm  P,  and  NePermSet  sP  as  follows: 

eq  emptyPermSet  I  C  =  C  . 

eq  P  |  C  =  emptyPermSet  I  if  lt(P  >>  C,  C)  then  P  >>  C  else  C  fi  . 

eq  P  U  sP  |  C  =  sP  |  if  lt(P  »  C,  C)  then  P  »  C  else  C  fi  . 
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size 

2 

3 

total  states 
reduction 
final  states 
cpu  time  (ms) 
real  time  (ms) 

2,473 

50% 

19 

3,089 

4,861 

176,897 

81% 

95 

821,392 

911,346 

Table  2:  Metrics  for  basic  specification  with  on-the-fly  symmetry  reduction. 


Recall  that  the  goal  is  to  compute  with  representatives  of  the  equivalence 
classes  of  a  quotient  system.  Since  transitions  on  representative  states  do  not 
necessarily  reach  representative  states,  whenever  a  transition  leads  to  a  state  s, 
this  state  must  be  mapped  to  the  representative  of  [s],  that  is,  to  *s. 

The  next  question  is  how  to  detect  that  a  transition  has  occurred.  For  this 
introduce  a  subsort  Marker  of  Msg,  with  constants  ?  and  ! .  Modify  each  rule  in 
R  by  adding  ?  to  its  left  side,  and  !  to  its  right  side.  Given  an  initial  state 
with  a  single  pretransition  marker  ?,  the  consumption  of  ?  and  appearance  of  ! 
indicates  that  a  transition  has  occurred.  Then  the  representative  state  can  be 
selected  before  reintroducing  ?. 

eq  {  !  C  }  =  {  ?  (all-perms  I  C)  }  . 


Table  2  shows  the  results  obtained  when  using  the  on-the-fly  state-space  reduc¬ 
tion  just  described. 


5  Strong  Consistency 

The  protocol  described  in  Section  3  is  a  simplification  of  the  Chain- Replication 
protocol  described  in  [7].  The  property  that  should  hold  for  this  protocol  should 
hold  also  for  its  simplification.  It  requires  that  query  and  update  operations  be 
executed  in  some  sequential  order,  and  that  the  effects  of  update  operations 
be  reflected  in  the  results  returned  by  subsequent  query  operations.  Thus,  the 
correctness  of  this  protocol  requires  that  the  value  a  server  has  at  one  time 
agree  with  the  value  a  client  will  receive  at  a  later  time.  The  protocol  presented 
in  Section  3  does  not  permit  the  verification  of  this  property.  It  is  a  minimal 
specification,  in  which  the  state  is  as  simple  as  can  be  to  describe  the  protocol. 
The  strong-consistency  property  the  protocol  should  satisfiy  requires  a  state 
with  more  information.  Information  that  is  specific  to  each  client.  This  section 
transforms  the  specification  presented  in  Section  3  into  one  that  will  support 
the  verification  of  the  strong-consistency  property  of  the  client-server  protocol. 

An  important  form  of  property  in  linear  temporal  logic  is 

□(</>->  (OV0). 

This  means  that  for  any  path,  whenever  a  state  satisfies  property  <f>  there  will 
be  some  later  state  in  the  path  that  will  satisfy  property  ip.  The  form  of  the 
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property  the  client-server  protocol  should  satisfy,  however,  is  of  the  form: 

VX.V  i.U^X)  ^  {OiPi{X))). 

Here  X  is  a  value  the  server  assigns  to  the  object,  and  i  identifies  a  client.  The 
predicate  <j>i(X)  states  that  the  server  replies  to  client  i  with  value  X\  while 
predicate  ipi(X)  states  that  client  i  receives  X  in  a  reply.  No  such  binding  of 
the  variable  X ,  however,  is  expressible  in  linear  temporal  logic. 

In  fact,  the  property  the  client-server  protocol  should  satisfy  in  all  states  is 
concerned  not  only  with  the  eventual  value  the  client  will  receive,  but  also  with 
the  value  it  currently  has.  Thus,  the  form  of  the  property  is  more  complex  than 
the  one  described  above,  and  remains  not  directly  expressible  in  linear  temporal 
logic.  So  we  transform  the  specification  of  Section  3  to  be  able  to  verify  this 
property. 

That  specification  does  not  keep  any  information  about  the  required  agree¬ 
ment  between  server  and  client.  This  will  now  be  added.  The  server  is  the 
keeper  of  the  value  of  the  object;  while  a  client  may  request  update  and  query 
operations.  These  are  not  instantaneous,  so  we  define  what  it  means  for  a  client 
and  server  to  agree  on  the  value  of  the  object. 

This  protocol  allows  a  client  to  have  at  most  one  outstanding  request  for  an 
operation.  A  client  initiates  the  operation  by  sending  a  request,  marked  by  the 
attribute  outstanding  becoming  true.  The  server  eventually  receives  it,  processes 
it,  and  replies  to  the  client.  When  the  client  receives  the  response  its  outstanding 
attribute  becomes  false,  and  the  operation  is  completed. 

With  the  reception  of  the  reply  the  client  updates  its  value  of  the  object. 
This  should  result  in  the  client  agreeing  with  the  value  the  server  had  when  it 
processed  the  last  request  by  this  client.  This  is  the  condition  that  should  hold 
whenever  the  outstanding  attribute  has  value  false. 

There  are  three  stages  while  a  request  is  outstanding.  The  first  begins  when 
the  request  is  sent  (with  send-query  or  send-update).  The  request  becomes  part 
of  the  configuration.  The  second  begins  when  the  get-request  rule  removes  this 
request  from  the  configuration  and  enqueues  it  in  the  pending  attribute  of  the 
server.  During  these  two  stages  the  agreement  should  still  be  that  the  client 
should  have  the  same  value  of  the  object  as  the  server  had  when  the  server 
processed  the  last  request  by  this  client. 

The  last  stage  begins  when  the  server  processes  the  request,  which  may  be 
with  the  respond-to-query  or  respond-to-update  rule,  and  sends  the  reply.  This 
reply  to  the  client  becomes  part  of  the  configuration.  The  agreement  condition 
during  this  stage  is  that  the  client  should  have  the  value  the  server  had  when  it 
processed  the  previous  to  last  request  by  this  client,  or  if  this  is  the  first  request 
by  this  client,  the  client  should  have  its  initial  value  of  the  object. 

To  be  able  to  determine  whether  the  required  agreement  holds  at  all  times 
the  specification  will  have  auxiliary  data. 

sort  AuxData  .  subsort  AuxData  <  Msg  . 
op  (_[_]_)  :  Value  NzNat  Value  ->  AuxData  . 
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size 

2 

3 

total  states 
cpu  time  (ms) 
real  time  (ms) 

9,025 

1195 

1212 

3,253,621 

668,728 

7,046,545 

Table  3:  Metrics  for  specification  that  supports  verification  of  strong  consistency. 


For  each  client,  the  values  the  server  had  when  it  processed  the  last  and  previous 
to  last  requests  will  be  kept:  (p  [i]  l). 

The  only  other  change  to  the  original  specification  is  to  the  rules  that  process 
the  requested  operations: 


rl 

[respond-to-query]  : 
(P  [N]  V’)  <  server 

1  value 

:  V,  pending  : 

:  query [  N  ]  ;  Q  > 

=> 

(VJ  [N]  V)  <  server 

1  value 

:  V,  pending  : 

:  Q  >  reply-to [N 

rl 

[respond-to-update] 

(P  [N]  VO  <  server 

1  value 

:  VJ , pending  : 

:  update [  N  :  V]  ; 

=> 

(V’  [N]  V)  <  server 

1  value 

:  V,  pending  : 

:  Q  >  reply-to [  N 

which  now  must  update  the  auxiliary  data  to  reflect  the  value  the  server  had 
when  it  processed  the  last  and  previous  to  last  operations  requested  by  this 
particular  client. 

So  in  all  states  a  client  should  have  one  of  the  last  two  values  the  server 
had  when  processing  a  request  by  this  client.  During  the  third  phase  of  an  out¬ 
standing  request  by  client  i  the  configuration  (i.e.  state)  includes  reply— to  [i  :  v] 
as  well  as  the  auxiliary  datum  (p  [i]  v).  In  any  state  during  this  stage  client 
i  should  have  value  p.  Otherwise,  when  there  is  no  reply  for  client  i,  it  should 
have  the  last  value  in  (p  [i]  v),  that  is,  v. 

The  search  command  can  be  used  to  verify  that  this  property  holds  for  all 
clients  in  all  states.  Simply  search  for  any  state  that  satisfies  the  negation  of 
the  required  property.  The  following  search  command  seeks  states  that  violate 
the  agreement  between  server  and  client  that  was  described  above. 

search  {  init(size)  }  =>* 

{  <  client  I:NzNat  I 

request-count  :  K:Nat,  outstanding  :  B:Bool,  value  :  V’ : Value  > 

(  P: Value  [I:NzNat]  V: Value  )  C : Configuration  } 
such  that 

(  (reply-to [I :NzNat  :  V: Value]  in  C : Configuration) 
and  (VJ : Value  =/=  P: Value)  ) 

or  (  (not  (reply-to [I :NzNat  :  V: Value]  in  C : Configuration)  ) 
and  (V’ : Value  =/=  V: Value)  )  . 

If  no  such  state  is  found  then  the  instantiation  of  the  protocol  that  was  subjected 
to  this  search  satisfies  the  strong  consistency  property. 

Instantiations  of  the  specification  with  one  server  and  two  clients,  and  with 
one  server  and  three  clients,  were  found  to  be  strongly  consistent.  Table  3  shows 
the  results  of  the  experiments  that  obtained  these  verifications. 
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size 

2 

total  states 

4519 

final  states 

90 

epu  time  (ms) 

5357 

real  time  (ms) 

9053 

property  verification 

epu  time  (ms) 

5046 

real  time  (ms) 

5052 

Table  4:  Metrics  for  symmetry  reduction  in  the  verification  of  strong  consistency. 


Table  4  gives  the  metrics  for  the  search  of  all  final  states,  and  for  the  verifi¬ 
cation  of  consistency  using  symmetry  reduction. 


6  Partial-Order  Reduction 

Section  4  describes  how  to  compute  with  representative  states.  This  section 
describes  how  to  compute  representative  paths.  Having  introduced  the  prop¬ 
erty  the  client-server  should  satisfy  it  becomes  possible  to  consider  partial-order 
reduction  (POR).  This  approach  is  based  on  properties  that  some  transitions 
have:  for  some  pairs  of  transitions  the  order  in  which  they  are  executed  does  not 
matter,  and  some  transitions  do  not  affect  whether  a  property  holds.  Usually 
POR  techniques  are  combined  with  model-checking  algorithms.  Here,  instead, 
the  POR  approach  is  used  to  modify  the  specification  of  the  system. 

The  main  point  about  the  POR  approach  is  that  in  exploring  the  state 
space  some  transitions  are  ignored.  A  finite  state  transition  system  is  a  tuple 
(S,So,T,AP,L),  where  S'  is  a  finite  set  of  states,  So  C  S  is  a  set  of  initial 
states,  T  is  a  finite  set  of  transitions,  such  that  each  a  £  T  is  a  partial  function 
a  :  S  — »  S,  AP  is  a  finite  set  of  propositions,  and  L  :  S  — >  2AP  is  a  labelling 
function.  The  set  of  enabled  transitions  in  state  s  is  denoted  by  enabled(s). 
If  a  £  enabled(s),  the  state  reached  by  taking  a  is  denoted  by  a(s).  POR 
techniques  explore  only  transitions  in  some  set  ample(s)  C  enabled(s). 

Two  concepts  are  used  to  define  such  a  set.  First,  an  independence  relation 
I  C  T  x  T  that  is  symmetric  and  antireflexive.  Transitions  a,  (3  £  I  if  for 
all  states  s  £  S,  if  a  £  enabled(s),  then  (3  £  enabled(s)  if  and  only  if  {3  £ 
enabled(a(s)).  Second,  a  transition  a  is  invisible  if  for  all  s  £  S,  L(s)  —  L(a(s)). 
Based  on  these  concepts  [1]  gives  four  conditions  that  ample(s)  must  satisfy  in 
order  to  preserve  the  satisfaction  of  properties  invariant  under  stuttering. 

Consider  these  concepts  for  the  client-server  protocol.  In  Maude  transitions 
are  specified  by  rules,  usually  having  variables.  Partially  instantiating  the  rules 
of  the  client-server  protocol  the  following  transitions  are  used  to  define  the 
independence  relation:  qi,  client  i  makes  a  query;  tq,  client  i  requests  an  update; 
gi,  client  i  gets  a  reply;  gqi  and  gut,  the  server  gets  a  query  and  an  update  from 
client  i:  and  sqi  and  sui,  the  server  responds  to  a  query  and  an  update  from 
client  i.  Table  5,  in  which  i  and  j  are  distinct  indices,  gives  the  dependencies 
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gui 

99i 

SUi 

sqi 

guj 

99.i 

SUj 

sqj 

Ui 

9i 

9i 

u.i 

9j 

9.1 
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i 

d 

i 

d 

d 

i 

i 

d 

i 

i 

i 

i 

i 

99i 

i 

d 

i 

d 

d 

i 

i 

i 

i 

d 

i 

i 

i 

i 

SUi 

d 

i 

d 

d 

i 

i 

d 

d 

i 

i 

d 

i 

i 

i 

sqi 

i 

d 

d 

d 

i 

i 

d 
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i 

i 
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i 

i 
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Ui 

d 

i 

i 

i 

i 

i 

i 

i 

d 

d 

d 

i 

i 

i 

n 

i 

d 

i 

i 

i 

i 

i 

i 

d 

d 

d 

i 

i 

i 

9i 

i 

i 

d 

d 

i 

i 

i 

i 

d 

d 

d 

i 

i 

i 

Table  5:  Dependencies  Table  for  client-server  protocol 


among  these  transitions. 

In  checking  the  consistency  property  with  the  search  command  no  explicit 
atomic  propositions  are  defined.  The  search  pattern,  however,  corresponds  to 
a  finite  set  of  atomic  propositions.  The  transitions  that  affect  the  satisfaction 
of  these  propositions  are  the  ones  that  change  auxiliary  data,  or  the  values  the 
clients  and  server  have.  The  remaining  transitions,  Ui,qi,gUi  and  gqi,  are  the 
invisible  transitions. 

The  basic  idea  presented  here  to  take  advantage  of  the  POR  approach  is  that 
the  representation  of  the  state  may  have  two  parts:  one  part  allows  the  appli¬ 
cation  of  rules,  the  other  one  is  frozen  and  does  not.  In  [6]  such  a  partitioning 
keeps  a  part  of  the  state  on  which  no  transitions  are  enabled  in  the  frozen  part 
of  the  state.  Here,  to  implement  a  POR  technique,  the  frozen  part  of  the  state 
also  includes  parts  of  the  state  that  have  enabled  transitions,  but  that  are  not 
in  ample(s). 

Consider  conditions  ample(s)  must  satisfy.  Condition  C2  requires  that  if 
ample(s)  ^  enabled(s)  then  every  a  £  ample(s)  must  be  invisible.  While  one 
consequence  of  condition  Cl  is  that  all  transitions  in  enabled(s)\ample(s)  must 
be  independent  from  those  in  ample(s). 

Consider  whether  ample(s)  could  consist  of  the  transitions  of  an  individual 
client.  Whenever  outstanding  is  false  and  request-count  <  lim  for  client  i,  invis¬ 
ible  transitions  ut  and  qi  are  enabled.  Transitions  dependent  on  these  cannot 
be  simultaneously  enabled.  Thus,  any  other  enabled  transitions  would  be  inde¬ 
pendent  from  these.  Now  consider  condition  Cl,  which  requires  that  for  every 
path  in  the  full  state  graph  that  starts  at  s  some  transition  in  ample(s)  must 
be  executed  before  a  transition  dependent  on  one  on  ample(s).  The  discarded 
paths  start  with  prefixes  of  independent  transitions.  Let  a  be  the  first  transi¬ 
tion  in  these  paths  that  is  dependent  on  {iii,gi}-  Suppose  it  is  a  transition  of 
client  i.  Table  5  indicates  that  it  could  be  one  of  these:  Ui,qi,gi.  The  first  two 
are  in  ample(s),  satisfying  Cl.  For  gi  to  be  enabled  either  u-t  or  qi  must  have 
been  executed  before,  but  the  transitions  that  were  executed  were  independent 
of  {ui,gi},  so  this  case  is  impossible.  Now  suppose  a  is  one  of  the  dependent 
server  transitions:  gui  or  gqi.  Again  this  case  cannot  arise  since  they  must  be 
preceded  by  iq  or  q, ,  respectively.  This  client-server  specification  has  no  cycles 
so  condition  C3  is  satisfied.  Thus,  ample(s)  could  be  gt}.  In  such  a  state 
the  entire  configuration  except  client  i  would  be  in  the  frozen  part  of  the  state. 
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Further  examination  of  Table  5  and  the  conditions  ample(s)  must  satisfy  re¬ 
veal  that  there  is  no  ample(s)  that  is  a  proper  subset  of  enabled(s)  and  contains 
transitions  of  the  server. 

As  in  the  implementation  of  symmetry  reduction,  markers  are  used  to  indi¬ 
cate  when  a  transition  has  occurred,  and  provide  for  an  opportunity  to  discover 
ample(s).  Since  the  only  ample(s)  is  the  one  discussed  above,  a  new  marker 
is  introduced:  op  !  :  NzNat  ->  Marker  which  is  used  to  indicate  that  Ui  and  gi 
are  enabled. 

rl  [get-reply]  : 

?  reply-to[  N  :  V*  ] 

<  client  N  I  request-count  :  K,  outstanding  :  true,  value  :  V  > 

=>  <  client  N  I  request-count  :  K,  outstanding  :  false,  value  :  V’  > 

!  (N)  . 

There  may  be  several  clients  that  are  enabled  to  send  requests,  so  the  rep¬ 
resentation  of  the  state  includes  a  list  of  the  ids  of  those  clients.  Anytime  the 
above  transition  is  executed  the  id  of  the  client  is  entered  in  the  (ordered)  list. 

op  _ | *_  :  Configuration  Configuration  ->  Configuration 
[ctor  frozen  (2)  format  (n++i  n — i  n++i  n — i)]  . 
op  _#{_}  :  NzNatList  Configuration  ->  TConf iguration 
[ctor  frozen(l)  format  (n  n  n  n++i  n — i  n)]  . 
op  _#[_]  :  NzNatList  Configuration  ->  TConf iguration  [ctor  frozen(l  2)]  . 

Only  states  that  have  a  proper  ample(s)  are  partitioned  in  two,  but  after  the 
transition  is  executed,  a  new  ample  set  gets  constructed. 

eq  (!  C)  I*  C'  =  !  C  C'  . 
eq  (!  (I)  C)  I*  C’  =  !  (I)  C  C’  . 

If  client  i  has  just  been  enabled  to  send  requests,  then  i  gets  inserted  in  the  list 
of  ids. 

eq  L  #  {!  (I)  C}  =  (I  ~>  L)  #  [C]  . 
eq  L  #  {!  C}  =  L  #  [C] 

The  first  id  in  the  list  determines  the  ample  set. 

eq  nil  #  [C]  =  nil  #  {?  C}  . 
ceq  I,  L  #  [  <  client  I  I 

request-count  :  N,  outstanding  :  B,  value  :  V  >  C  ] 

=  L  #  {  (?  <  client  I  I 

request-count  :  N,  outstanding  :  B,  value  :  V  >  )  I*  C  } 

if  N  <  lim  . 

ceq  I,  L  #  [  <  client  I  I 

request-count  :  N,  outstanding  :  B,  value  :  V  >  C  ] 

=  L  #  [  <  client  I  I 

request-count  :  N,  outstanding  :  B,  value  :  V  >  C  ] 

if  N  >=  lim  . 

Once  the  ample  set  has  been  determined,  and,  if  necessary,  the  state  has  been 
partitioned,  the  pretransition  marker  is  reintroduced.  Table  6  shows  the  result 
for  the  case  with  one  server  and  two  clients.  The  property  was  checked  by  three 
searches,  one  for  each  of  the  forms  the  state  can  take. 
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size 

2 

total  states 
reduction 
epu  time  (ms) 
real  time  (ms) 

8815 
2.3% 
1321,  907,  895 
1332,  918,  903 

Table  6:  Metrics  for  the  application  of  the  POR  technique. 


7  Conclusion  and  Future  Work 

The  design  and  development  of  highly  assured  distributed  systems  is  challenged 
by  the  state-explosion  problem,  and  often  by  the  complexity  of  the  properties  to 
be  verified.  We  developed  two  techniques  for  the  reduction  of  the  state  space:  an 
on-the-fly  symmetry  reduction,  and  an  on-the-fly  partial-order  reduction.  We 
also  developed  a  technique  for  verifying  strong,  nontrivial  properties  that  are 
not  directly  expressible  in  linear  temporal  logic.  A  couple  of  points  are  worth 
noting  in  appraising  the  value  of  this  work. 

First,  in  practice  much  of  what  is  considered  analysis  of  distributed  systems 
is  performed  using  simulations.  These  analyses  examine  only  a  few  behaviors 
of  the  system.  A  Maude  specification  is  executable,  and  so  it  can  also  be  used 
for  simulations  by  simply  executing  it.  This  may  be  used  to  perform  some  ini¬ 
tial  debugging  of  the  specification  or  to  gain  a  greater  understanding  of  the 
system  being  developed.  Simulation,  however,  whether  formal  or  informal,  is 
not  verification,  and  is  not  a  foundation  for  trusted  systems.  The  techniques 
presented  here  support  verification  through  exhaustive  exploration  of  the  state 
space.  They  contribute  to  a  framework  in  which  it  is  possible  to  document  and 
specify,  simulate  and  verify  a  system  by  modularly  extending  or  transforming 
formal,  object-oriented  specifications,  and  thus  they  contribute  to  the  advance¬ 
ment  of  formal  support  for  the  design  of  distributed  systems. 

Second,  there  is  no  single  technique  that  will  eliminate  the  state-explosion 
for  all  specifications.  What  are  needed  are  techniques  that  can  be  composed 
and  combined.  The  techniques  developed  in  this  study  impose  no  restrictions 
on  the  specifications  on  which  they  are  applied,  and  can  be  easily  composed. 
They  are  implemented  by  simple  transformations  and  modular  extensions  of  the 
original  specifications.  No  translation  to  different  logics  are  needed. 

Additional  research  needs  to  investigate  general  and  protocol-specific  opti¬ 
mizations  to  the  two  state-space  reduction  techniques  that  will  reduce  the  time 
and  memory  overhead.  Furthermore,  in  order  to  verify  larger  and  more  com¬ 
plex  systems,  composition  of  these  and  other  techniques  need  to  be  studied,  and 
applied  to  a  collection  a  protocols,  including  some  common  benchmarks. 

A  new  area  of  research  is  to  explore  notions  and  characterizations  of  data 
independence,  which  would  permit  the  verification  of  large  and  infinite  systems 
by  the  verification  of  much  smaller  systems. 
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